🔴 Contributor Check: HIGH

Automated check by AGT Contributor Check.

PR Review Summary

Verdict: ⚠️ Ready for human review

@microsoft-github-policy-service agree

@giskard09 Thanks for turning #2208 into a structured proposal — this is the right shape and the additive-schema choice is exactly right. Comments below, grouped by severity.

Blocking (technical)

1. action_ref canonicalization isn't yet deterministic. "Concatenated with || … with no separator" is contradictory; there are no length prefixes (so ab|cd and abcd| collide); scope is typed as a string but agt-evidence.json — external anchor for independently verifiable compliance evidence #2208 implied a structured object; Unicode normalization form is unspecified. Once action_ref ships it's a breaking compliance change to alter, so let's nail this down. Recommend either RFC 8785 JCS or deterministic CBOR with explicit field tags, rather than ad-hoc concatenation.
2. verify() -> bool is too thin to support the three CLI exit codes (0/1/2) you specify. Suggest a result type or typed exceptions distinguishing not-found / hash-mismatch / backend-unavailable. Also: where does the inclusion proof live for Merkle-log backends? Specify per-backend rather than leaving it in metadata: dict[str, Any].
3. "No network access to operator infrastructure" ≠ "fully offline." Rekor / chain / WORM verification all require network access to the anchor backend. One clarifying sentence avoids misunderstanding.

Governance

4. Reference backend list shouldn't include a specific commercial/personal product. S3 Object Lock and Sigstore Rekor are infrastructure primitives; Mycelium Trails is your project. Suggest keeping WORM + Rekor as in-tree references and replacing "Priority 3 — Mycelium Trails" with a generic "on-chain anchor (see community plugins)" entry. A Mycelium plugin is welcome as a separate community repo once the core interface lands.
5. Normative dependencies on external/personal repos (azender1/SafeAgent, giskard09/argentum-core#7) — please inline the relevant canonicalization rules into this proposal, or mark those refs as informational/non-normative. AGT's on-disk format can't take a normative dependency on third-party repos.
6. Minor: **Author:** @giskard09 (Rama / Mycelium) — please drop the affiliation from the doc header (keep it in the PR description). Standard practice for vendor-neutral toolkits.

Spec gaps

7. Anchor failure semantics at write time — block the action? buffer and retry? fail-open? This is a critical behavioral contract for regulated deployments.
8. Batching — per-record anchoring is expensive on Rekor and prohibitive on-chain. At minimum acknowledge batched-Merkle-root anchoring as a v2 path so the v1 interface doesn't preclude it.
9. Append-only / monotonic-time conformance requirement for backends. Without this, an operator could rewrite-and-re-anchor. Should be a stated requirement on any conformant EvidenceAnchor, not implicit.
10. Plugin discovery — flag this as a security surface, not just an open question. Suggest explicit registration as the default; entry-point auto-discovery opt-in only.
11. Receipt-vs-raw-evidence: does the anchor cover the signed receipt from verifiable-compliance-receipts.md or the raw evidence? Different audit guarantees — needs one sentence.
12. Compliance table — please soften "satisfies" → "supports" throughout, especially for EU AI Act Art. 12 (Art. 12 requires automatic logging; tamper-evidence is supportive, not literally required). Auditors read this language strictly.

Would strengthen the proposal

• An Impacts section: latency added to the action path, per-anchor cost (Rekor ~free; on-chain $0.001–$0.10/tx), evidence-file growth, availability coupling to anchor backend, security surface from plugin loading.
• Two Mermaid diagrams — write path and audit-verify path. The whole point of this proposal is the trust boundary, and a diagram makes it visible at a glance. Happy to suggest specific ones if useful.

Thank you, thi s is a very promising direction, addresses a real gap, just needs the canonicalization tightened, the vendor-neutrality cleaned up, and the operational impacts spelled out before this is mergeable as a design baseline.

Thank you for the detailed review — this is exactly the kind of signal that makes a proposal shippable. Working on v2 now.

Quick alignment check on two design decisions before I push:

1. For action_ref canonicalization: RFC 8785 JCS over the current ad-hoc approach — agree this is the right call. Any preference on whether timestamp_ms stays as int64 big-endian (current APS wire format) or gets serialized as a number in the JCS object?

2. Failure semantics: proposing fail-open (log-and-continue) as the default with fail-closed as a config option for regulated deployments. Does that match AGT's behavioral contract expectations, or do you prefer fail-closed as the default with explicit opt-out?

Everything else in your review is clear — will address all blocking, governance, and spec gap items in v2.

Both good questions — quick takes:

1. timestamp_ms under JCS

Drop the int64-big-endian rule entirely; it can't coexist cleanly with JCS without re-introducing the drift we're trying to eliminate. Two options that both work:

• Preferred: RFC 3339 string, UTC only, mandatory Z, fixed 3-digit millisecond precision ("2026-05-13T10:00:00.123Z"). Future-proof against ns/μs precision later, matches Sigstore/Rekor conventions (which helps your Priority 2 backend), human-readable in the evidence file.
• Acceptable: keep it as a JSON number named timestamp_ms, but explicitly forbid values exceeding 2^53−1 and forbid sub-millisecond precision in v1. JCS will serialize it deterministically inside that range.

Either is fine; just pick one and remove the binary wire format.

2. Failure semantics

I'd push back on fail-open as the default. AGT's positioning (governance, zero-trust, OWASP Agentic Top 10) and the regulatory framing in your own proposal (EU AI Act Art. 12, FCA SYSC 9.1) both argue against silently-incomplete audit trails. Comparable tools (OPA, Sigstore policy-controller, Kyverno) all default to enforce/deny on the enforcement path. A fail-open default in a Microsoft-owned governance toolkit is the kind of thing that gets flagged in security review.

Suggest a 3-mode config instead of a binary, since the real-world pattern doesn't fit neatly into either:

• enforce (default) — action blocks if the anchor write fails. Fail-closed.
• queue — action proceeds; the anchor request is written to a durable local queue and retried with backoff; the evidence record is tagged anchor_status: "pending" and the auditor's verify flags it. This is what most high-throughput regulated systems actually want, since it preserves availability without dropping the audit guarantee.
• best_effort — log-and-continue. Explicit opt-in for dev / non-regulated use. Records marked anchor_status: "skipped".

Hard rule regardless of mode: any record not successfully anchored MUST be marked in the evidence file (anchor_status: "pending" | "failed" | "skipped"). Silent fail-open is the actually-bad outcome — making the gap visible to the auditor is the non-negotiable part.

Aslo another point

3. Observability — please make this explicit in v2

Don't leave "anchor failure emits a log/metric" implicit. Spec it:

Anchor failures (any mode) MUST emit a structured event on AGT's existing telemetry channels — not only as an anchor_status field on the evidence record. The evidence file alone is not a sufficient failure-detection surface (it's the artifact the control was supposed to protect; relying on it to also report its own failure is circular, and an attacker who can suppress evidence writes hides the failure).
Suggest concrete names so operators can alert on them consistently:
Log event: agt.evidence.anchor.failed with fields {backend, action_ref, error_class, attempt}
Metrics: agt_evidence_anchor_failures_total{backend,reason} counter, agt_evidence_anchor_pending gauge (for queue mode backlog), agt_evidence_anchor_latency_seconds histogram
OpenTelemetry span on the anchor call, with the failure recorded as a span event so it shows up in existing traces
Whatever the existing AGT logging conventions are, anchor events should follow them rather than inventing a new format.
This is what bridges "the proposal" to "what an SRE deploys and a SOC can alert on" — without it, every operator reinvents it differently and the audit story fragments.

Looking forward to v2.

v2 pushed — addresses all three points:

1. timestamp_ms → RFC 3339 string (UTC, Z, 3-digit ms), int64 big-endian removed throughout
2. Failure semantics → 3-mode config (enforce default / queue / best_effort) with hard rule: any unanchored record MUST be marked anchor_status
3. Observability section added: agt.evidence.anchor.failed log event, three metrics (failures_total, pending gauge, latency histogram), OTel span on anchor call

All other blocking/governance/spec-gap items from your first review also incorporated. Ready for another pass when you have time.

Thanks for the thorough review — v3 pushed.

Changes from v2:

• Mycelium Trails moved out of the reference backends list and into the community plugins path. The proposal now ships with WORM + Sigstore Rekor only as in-tree references.
• azender1/SafeAgent and argentum-core#7 references moved to an explicit "Related work" section at the end of the document, marked informational.
• Added a forward-looking note on anchor_batch() at the end of the EvidenceAnchor interface section to keep v1 extensible without breaking changes.
• "satisfies" → "supports" throughout the compliance table (EU AI Act Art. 12, FCA SYSC 9.1).

Let me know if anything else needs adjustment before this is ready to land.